Closed Bug 294399 Opened 19 years ago Closed 19 years ago

rebrand firefox for deer park

Categories

(Firefox :: General, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox1.5

People

(Reporter: asa, Assigned: mconnor)

References

Details

Attachments

(6 files, 3 obsolete files)

We need to rebrand this release. 

Replace Firefox with "Deer Park Alpha 1" and drop the official branding artwork.
Flags: blocking1.8b2+
Flags: blocking-aviary1.1+
Chase is flipping build system to remove 

--enable-official-branding
no changes to UA.
deb, can you point to the start page doc you are working on?
need to figure out what we want to do for desktop icons and install path....

easiest just to leave as is.  that wouldn't allow 1.0.x and deerpark on the same
systems.

profile incompatiblities might make it hard for some users to go back 1.0 after
running deerpark
Attached image about "Deer Park" image
Are we affecting the UA string for this release?  I think we probably shouldn't.
darin, no, see comment 2.  I think that was discussed and decided the same way a
couple weeks ago.
Whoops, sorry for the SPAM.  What about other things like the registry keys,
profile location, and the default install path?  Will the value of
nsIXULAppInfo::name be changed from "Firefox" to something else?  I think we
should avoid making too many changes here.
I don't think it's worth it to make further changes. The goal for the rebranding
is to differentiate these previews from our final releases and I think we've
accomplished that. 
Attached patch rebrand to deer park (obsolete) — Splinter Review
ok, so this rebrands the installer and the app to use "Deer Park" as the
shortname and "Deer Park Alpha 1" as the long name. (So where it says "Firefox"
it'll say "Deer Park" and where it says "Mozilla Firefox" it'll say "Deer Park
Alpha 1").

This does change the default install path, but I think that's a good thing.  We
want users to be able to go back to their existing install if there's problems,
and I've tested it without any negative effects (it doesn't change profile
patches or exe names or anything really dangerous).  This changes the
desktop/quick launch/start menu entries as well, so this makes the alpha a safe
install for existing users who don't want to lose their existing setup.

To-do:

Placeholder URL on www.mozilla.org for the Deer Park page (I can do that, and
dria can replace it with real content based on what's on the wiki).
Change "Firefox Start" to something appropriate to what we're calling the Deer
Park start page.

Both of these are trivial, where and what we're calling it is the stopper. 
Otherwise we're good to go.
You'll have to give me more information about what you would need/want for a
start page -- the wiki documentation is essentially non-existant, and seems
unlikely to get much more content any time soon (unless there are docs being
worked on that I don't know about).

I think the idea was supposed to be a list of new features/API changes/other
things that affect developers, both extension and web, sort of like a
highly-detailed release notes setup.

Asa was going to collate a bunch of different relnote lists, and do a call for
feedback from everyone who's landed stuff since 1.7.x.  I may be remembering
wrong, but that was the idea.  And there should have been more docs, yes... we
(meaning Mozilla developers) still aren't good at that whole "documenting" thing.

If I'm right on this, I'll create something as a placeholder tonight, and get
these branding changes landed.
Status: NEW → ASSIGNED
"so this makes the alpha a safe install for existing users who don't want to
lose their existing setup."

This isn't really true.  We'll be affecting installed extensions and changing
the profile in interesting ways that may cause users headaches when switching
back-n-forth between this application and firefox 1.0.  I think that those are
the headaches we want to learn about now rather than later, so this is probably
a good thing.

I am a bit concerned that we are changing the registry keys used to locate the
current version of Firefox.  That just means that any third-party apps that rely
on our registry keys to locate the installed version of Firefox will not find
this alpha release.  That's probably OK... but maybe just a little concerning
that we aren't fully testing what a real Firefox 1.1 release would be like. 
Perhaps that will all be tested later on when we do a Firefox 1.1 PR.
Attachment #183785 - Attachment is obsolete: true
Comment on attachment 184020 [details] [diff] [review]
rebrand, remove recapture homepage code, change default homepage

ok, my editor config was stupid on the new box.  reattaching without the
spurious whitespace changes shortly
Attachment #184020 - Attachment is obsolete: true
I've put together a new page for summarizing the additions and changes in Deer
Park Alpha here:

http://developer-test.mozilla.org/docs/What%27s_New_in_Deer_Park_Alpha

If anyone can help fill in some of the blanks with a sentence or three of
explanation, it would be much appreciated.  I'll do a full edit once we get some
more content in place.
Attachment #184025 - Flags: review?(benjamin)
Comment on attachment 184025 [details] [diff] [review]
without the spurious whitespace changes

I'm tempted to say that the installer should keep saying "Firefox" even as the
rest of everything say Deer Park, just to avoid weird registry issues, but ok.
Attachment #184025 - Flags: review?(benjamin) → review+
Comment on attachment 184025 [details] [diff] [review]
without the spurious whitespace changes

just getting ducks lined up, we can land this once we're ready to spin builds. 
Will also need Asa's modded image of course.
Attachment #184025 - Flags: approval-aviary1.1a1?
There's a summary for all items on the new/changed features list except SVG and
<canvas>:

http://developer-test.mozilla.org/docs/What%27s_New_in_Deer_Park_Alpha
Sorry: also missing notes for PrefWindowV and Searchable Download Actions.
Comment on attachment 184025 [details] [diff] [review]
without the spurious whitespace changes

a=asa
Attachment #184025 - Flags: approval-aviary1.1a1? → approval-aviary1.1a1+
checked in for respins/testing.  Remember that this patch requires building
_without_ the --enable-official-branding switch, so if we respin with that we
won't be testing these changes properly.

Marking fixed for now.  I'll file a followup for undoing the naming-specific
changes after we ship a1
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
> Marking fixed for now.  I'll file a followup for undoing the naming-specific
> changes after we ship a1
So we won't reintroduce the reset homepage option for 1.1?
And why was it removed in the first place?
No.  Its been possibly the biggest source of complaints, especially with the
'full installer as upgrade' setup we currently have.  We talked about this in
the Deer Park meeting and everyone agreed that the best course of action was to
remove it permanently.
Depends on: 290704
No longer depends on: 290704
(In reply to comment #5)
> Created an attachment (id=183776) [edit]
> about "Deer Park" image

It looks like the image never made it to the tinderboxen.

Our extension is broken by this  name rebranding.  our extension rely on windows
registry to find  firefox entensions directory and copy files to
<firefox>/extensions directory.  But now, it cannot work.  How to  detect
firefox on system reliably ?   Firefox 1.1 will be "Deer Park",  will  Firefox
1.5  be  "The Ocho" ?    third party  need a reliable way to detect  firefox.
Firefox 1.1 will be Firefox 1.1, Deer Park is what we're labelling the alpha
releases as, but beta and final will be "Firefox"
Thanks clarification.   So the final Firefox 1.1  can still be detected by
HKLM\Software\Mozilla\Mozilla Firefox\CurrentVersion,  is it right ?

BTW,  we rely on the nightly image on mozilla.org  to test our product.  We
still want it to use HKLM\Software\Mozilla\Mozilla Firefox,   if it's
impossible,   we need build Firefox by ourselves,   enabling 
--enable-official-branding  can help,  is it right ?   And the official Firefox
1.1 and higher versions  will be built with " --enable-official-branding",  right ?

This is incomplete. Mac still identifies itself as Firefox. The application menu
is titled "Firefox" (and while the 'About' on that menu is "Deer Park Alpha 1",
the Quti and Hide both say "Firefox",) the application bundle itself is titled
"Firefox", and the About dialog/window says "Firefox" under the globe. 

The artwork is correct.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Also, the about image I attached at
https://bugzilla.mozilla.org/attachment.cgi?id=183776 hasn't showed up in any of
the platforms. 

-> Josh for mac stuff. 

Who can land the about image?
Assignee: mconnor → joshmoz
Status: REOPENED → NEW
Taking for mac bits
Assignee: joshmoz → bugs.mano
Attached patch mac build part, untested (obsolete) — Splinter Review
Attachment #184335 - Flags: review?(bryner)
Comment on attachment 184335 [details] [diff] [review]
mac build part, untested

According to Asa, we are supposed to leave Firefox in the copyright section.
Attachment #184335 - Flags: review?(bryner) → review-
tested.
Attachment #184335 - Attachment is obsolete: true
Attachment #184338 - Flags: review?(joshmoz)
Attachment #184338 - Flags: approval-aviary1.1a1?
Attachment #184338 - Flags: review?(joshmoz) → review+
I checked in the revised about image a few hours ago, it was in my checkin tree
but didn't go in previously.
Comment on attachment 184338 [details] [diff] [review]
mac build part (partly backed out)

a=asa
Attachment #184338 - Flags: approval-aviary1.1a1? → approval-aviary1.1a1+
Checked in, reassigning to Mike and resloving.

Checking in Makefile.in;
/cvsroot/mozilla/browser/app/Makefile.in,v  <--  Makefile.in
new revision: 1.77; previous revision: 1.76
done
Checking in macbuild/Contents/Info.plist.in;
/cvsroot/mozilla/browser/app/macbuild/Contents/Info.plist.in,v  <--  Info.plist.in
new revision: 1.11; previous revision: 1.10
done
Checking in macbuild/Contents/Resources/English.lproj/InfoPlist.strings;
/cvsroot/mozilla/browser/app/macbuild/Contents/Resources/English.lproj/InfoPlist.strings,v
 <--  InfoPlist.strings
new revision: 1.6; previous revision: 1.5
done
Assignee: bugs.mano → mconnor
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
Sorry for the "spam", but why do I get the feeling that this will finally be
fixed in time to put it all back again?
<sigh/> Backed out the APP_NAME change due to bustage (APP_NAME isn't used for
the diskimage, apparently), reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The diskimage name is taken from MOZ_APP_DISPLAYNAME, but can be overridden in
the makefile before you include packager.mk. See
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/packager.mk#99
Attachment #184338 - Attachment description: mac build part → mac build part (partly backed out)
haven't tested (yet).
Attachment #184350 - Flags: review?(benjamin)
...and i'm not sure if it should be mac-specific (the _display_name change), but
I'm not familier with the packaging code, and can't test it on a windows machine
right now.
Comment on attachment 184350 [details] [diff] [review]
more mac stuff...

ick: this will do in a pinch, but I'd like to find a more generic solution
(like a branding.mk file).
Attachment #184350 - Flags: review?(benjamin) → review+
Looks like trying to uninstall "Deer Park" has unintended behavior I think.  
Blocks: 295272
Sorry for the bugspam.  Last comment should have referenced bug 295272 : The new
Deer Park branded alphas breaks the standard firefox add/remove entry
(In reply to comment #28)
> Our extension is broken by this  name rebranding.  our extension rely on windows
> registry to find  firefox entensions directory and copy files to
> <firefox>/extensions directory.  But now, it cannot work.  How to  detect
> firefox on system reliably ?

Mike,

You should probably use the new Windows registry-based install location:
http://wiki.mozilla.org/Extension_Manager:Win32_Registry_Location

The "deer park" branded firefox 1.1 alpha release will still look in the
following locations for extensions:

 HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions
 HKEY_LOCAL_MACHINE\Software\Mozilla\Firefox\Extensions

FWIW, I raised this very concern in comment #14.  I know this will break
third-party global extension installers (that are not modified to use the Win32
registry based install location).  Since this problem will only affect the alpha
releases of Firefox 1.1, I don't think we should concern ourselves too much. 
However, this basically means that people using "firefox
--install-global-extension" to install global extensions are screwed (for the
deerpark alpha) because they will have no way to find out where firefox.exe
lives.  Hopefully those extension authors will learn about the Win32 registry
based install location and use that instead, which is anyways the preferred
method of installing global extensions into firefox on Windows.
Comment on attachment 184350 [details] [diff] [review]
more mac stuff...

Sigh, Deer\ Park (note the "\ ") isn't OK for hdiutil:

cd ../../dist;
/Users/mano/Development/Mozilla/ff4/mozilla/build/package/mac_osx/make-diskimag
e firefox-1.0+.en-US.mac.dmg firefox Deer\ Park
FOLDER_SIZE=61568
IMAGE_SIZE=63415
creating disk image
hdiutil: create: Only one image can be created at a time.
Usage:	hdiutil create <sizespec> [options] <imagepath>
	hdiutil create -help


However DeerPark works...
Any shell script guru in the yard? I guess that we need at least this change to
make-diskimage:

 
 # Create the image
 echo "creating disk image"
-hdiutil create -sectors $IMAGE_SIZE -fs HFS+ $DMG_TEMP_NAME -volname $VOLUME_NAME
+hdiutil create -sectors $IMAGE_SIZE -fs HFS+ $DMG_TEMP_NAME -volname "$VOLUME_NAME"

that, and a fix for the ditto call.
(In reply to comment #50)

> You should probably use the new Windows registry-based install location:
> http://wiki.mozilla.org/Extension_Manager:Win32_Registry_Location
Thanks Darin!  Yes. we can use this method. Unfortunately this feature came too
late(it's only  avaiable from 05/16/2005).  we followed
http://wiki.mozilla.org/Firefox:1.1_Extension_Manager_Upgrades to develop our
extension and use nightly build on mozilla.org to test it. we've passed
codefreeze deadline :-( 

> registry based install location).  Since this problem will only affect the alpha
> releases of Firefox 1.1, I don't think we should concern ourselves too much. 

Is that to say, Firefox 1.1 will rebrand back and use
HKLM\Software\Mozilla\Mozilla Firefox again ? it's very important to us.

And some code ( not extension) in our product need to detect the version of
Firefox, it relies on HKLM\Software\Mozilla\Mozilla Firefox\CurrentVersion ,it's
broken too.

I tried to use --enable-offical-branding to build Firefox on win32, but it seems
useless.  "Deer Park" is still written in windows registry.  Is there any
workaround for us to build temporary Firefox which has the same registry layout
as Firefox 1.1 ?
I'll attach a patch for backing out the branding changes tomorrow (need to do
this anyway since i intend to debrand the trunk after we ship a1, and hopefully
figure out a better plan for rebranding in general.

I understand that you passed code freeze, but perhaps you could make an
exception for this?  There are another couple months before final at least...
Attachment #184350 - Flags: approval-aviary1.1a1+
Mike, can you land this? a=asa on IRC.
Attachment #184384 - Flags: review?(mconnor)
Comment on attachment 184384 [details] [diff] [review]
Remove version in installer screen

r=me, a=asa on IRC
Attachment #184384 - Flags: review?(mconnor) → review+
Comment on attachment 184384 [details] [diff] [review]
Remove version in installer screen

a=asa
Attachment #184384 - Flags: approval-aviary1.1a1+
Comment on attachment 184350 [details] [diff] [review]
more mac stuff...

I have already noted this is incomplete. I will try to come up with something
shortly.
Attachment #184350 - Flags: approval-aviary1.1a1+
Comment on attachment 184350 [details] [diff] [review]
more mac stuff...

assuming a=asa.

Going to check this is in as DeerPark.dmg/DeerPark.app, on the app itself
(windows,menus) "Deer Park" (note the space) will be exposed.
filed bug 295307 on the make-diskimage limitation.
The tinderbox hardly tries to use Firefox.app after the build, gah.
That was the bustage, in case someone is familer with the tinderbox scripts...

/builds/tinderbox/firefox/Darwin_7.7.0_Depend/mozilla/xpfe/bootstrap/init.d/README
../../../dist/bin/init.d
/builds/tinderbox/firefox/Darwin_7.7.0_Depend/mozilla/obj/dist/Firefox.app/Contents/MacOS/firefox-bin
does not exist.
Error: binary not found: firefox-bin
So, we need someone w/ access to the tinderbox itself (to fix up the testing
script?)
where ready=s/Firefox.app/DeerPark.app on the mac tinderboxes scripts.
Attachment #184392 - Flags: review+
(In reply to comment #31)
> This is incomplete. Mac still identifies itself as Firefox. The application menu
> is titled "Firefox" (and while the 'About' on that menu is "Deer Park Alpha 1",
> the Quti and Hide both say "Firefox",) the application bundle itself is titled
> "Firefox", and the About dialog/window says "Firefox" under the globe. 
> 

(To clarify, all of this is already fixed in the hourly builds. However,the dmg
label/app-name/dock-label do need the last patch, I should point out that we
haven't done this on windows, where the executable name isn't as exposed as on mac).
The "firefox-bin" executable name should not be changed. It's fine to rename the
app bundle, but the internals shouldn't change at this point; we have too much
code hanging around that tests and depends on the executable name.
Benjamin, i didn't point to the executable itself, just to the app bundle (which
is considered as the executable from the user POV).
I changed ProductName on atlantia from "Firefox" to "DeerPark".  Its next build
will be a release build.  This should be all that's needed to use the new app name.
Checking in app/Makefile.in;
/cvsroot/mozilla/browser/app/Makefile.in,v  <--  Makefile.in
new revision: 1.81; previous revision: 1.80
done
Checking in installer/Makefile.in;
/cvsroot/mozilla/browser/installer/Makefile.in,v  <--  Makefile.in
new revision: 1.15; previous revision: 1.14
done
Chase, the ProductName change has two issues:
  * It shoudn't be done on candence, it seems we're still using offical branding
on this tinderbox (this is causing a bustage).
  * It shoudn't affect the profile-existence check(s), since the patches here do
not affect the profile folder location (this is causing orange on imola and
atlantia).

Noted on the tinderboxes as well.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Would someone with insight to the rebranding plan please announce in npm.l10n
what localizers are expected to do? And how much of this is temporarily and
what is there to stay, as someone may just land that seperatly to be able to
back it out for beta, if I understood things right.
(In reply to comment #54)
> I'll attach a patch for backing out the branding changes tomorrow (need to do
> this anyway since i intend to debrand the trunk after we ship a1, and hopefully
> figure out a better plan for rebranding in general.
Hi Mike, a1 is released, would you please let me know when to debrand the trunk ?
Mike, I'm hoping to back out the assorted branding changes tomorrow, need to
undo some tinderbox/build-box changes before I land that though.
(In reply to comment #73)
> Mike, I'm hoping to back out the assorted branding changes tomorrow, need to
> undo some tinderbox/build-box changes before I land that though.

Hi Mike, do you have time to work on this issue ?  Or Firefox 1.4 will revert
back to normal registry naming ?  It's planed for August, do you know what's
exact date ?
1.4 will be Firefox Beta, as I understand it.  Now, trunk may not follow the
same path, we have yet to figure out what we're doing with trunk branding at
this time.  There is no exact date set for Beta, as with all of our releases its
pretty much When Its Done.
Blocks: 313898
Blocks: 308973
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: